Compile in-process on OCaml domains in OCaml rewatch - #8781

Stacked on #8780.

This PR moves compilation into the OCaml rewatch process. Instead of starting bsc for every parse and compile, rescript links the compiler and runs requests on a bounded pool of OCaml 5 domains. That removes process start-up and pipe handling, which make the subprocess port slower than Rust on clean builds (see Performance below). It also opens the door to sharing compiler state between requests later. The compiler side, which makes requests safe to run repeatedly and in parallel and captures their output, is #8864.

Changes

• Rewatch schedules independent parse and compile requests, and namespace maps, on worker domains. By default that's at most 8, and one fewer than the CPU count; REWATCH_COMPILER_DOMAINS overrides it, and a count above the machine's limit is lowered to it. The worker that compiled a module also publishes its artifacts; build-state updates stay on the scheduling domain. Workers get a 2M-word minor heap, because with the default one they keep stopping each other for minor collections (see Memory below). PPXs and hooks still run as external processes.
• Compiler output is captured in memory, so builds need no temporary directory. Output written before an escaping exception is reported with the failed module.
• A termination signal stops the build at the next poll point, after the modules compiling in-process finish, so a stop never leaves a half-written artifact. Repeated signals are ignored: the npm launcher forwards the Ctrl-C the terminal already delivered.
• A damaged published AST, such as one cut short by a killed build, makes its module parse again instead of failing every later build.
• rescript format also runs on the embedded compiler. PPXs, js-post-build, --after-build and the lock-owner check are the only remaining subprocesses. RESCRIPT_BSC_EXE now only affects rescript-rust, and CONTRIBUTING.md says how to test a local compiler instead.
• The compiler's build identity is a digest of its sources, linked into the driver, so OCaml rewatch rebuilds after a compiler change without fingerprinting an installed executable. lib/bs/compiler-info.json still records the bsc.exe shipped next to rescript.exe; the VS Code extension reads bsc_path to find bsc.exe and the other platform binaries. A development build, which has no bsc.exe next to it, records the one in the installed @rescript/<platform> package.

Performance

Results

A real-world project with 1438 modules, on a MacBook Pro (Apple M1 Pro):

tests/tests (629 modules) on an idle Linux VM with 10 cores (arm64), median of 5 interleaved runs:

Clean builds are about 1.8x faster on both machines, with about 5x less CPU time, because no bsc process has to start for each file. Peak RSS is that of the largest single process: the in-process build keeps all compiler state in one process, whereas Rust rewatch spreads it over its bsc processes, whose combined memory was not measured. Builds after a one-file edit do little compiling, so they mostly cost fixed work such as package discovery and freshness checks.

Memory

• Worker domains get a 2M-word (16 MB) minor heap instead of OCaml's default 256k words, which made clean builds about 15% faster. Larger heaps help a little more but cost memory: 8M words are 5% faster for 210 MB more, 16M words 10% faster for 365 MB more.
• Peak RSS for tests/tests is about 410 MB with one domain and about 640 MB with the default 8.

Scaling with the domain count

tests/tests on the same VM:

Builds scale well up to 4 domains; 8 add almost nothing. Two things limit them:

• The end of the build. Once most modules are done, the build waits for the few slow ones that remain; with 8 domains, an average of 3.6 workers are busy. In tests/tests, one module dominates this because of slow compilation of its character range patterns (Character range patterns compile in quadratic time and memory #8866).
• Shared minor collections. In OCaml 5, a minor collection stops all domains and collects all their minor heaps whenever any one of them is full. Requests are almost 2x slower at 8 domains than at 1, while CPU time barely grows: they wait instead of working. Runtime traces (olly) show workers spend about 25% of their time at the barrier that ends each collection, which waits for the domain with the most to promote. Because each heap is collected before its young data has time to die, the same 226M words of allocation promote 29M words to the major heap instead of 6M.

The machine is not the limit: four independent single-domain builds run side by side were only 1.13x slower than one alone. Outside compilation, the build spends about 0.16 s in stages that run on one domain (preparing the package tree, parsing, starting up).

On one domain, compiling splits into typing (48%), translating to Lambda (12%), optimizing Lambda and generating JavaScript (13%), loading .cmi files (8%, about 4 per module) and writing .cmt files (7%).

Follow-ups

1. Worker processes instead of domains. Persistent single-domain processes running the same in-process requests each have their own GC, so the shared minor collections and their barrier wait go away. A crashing worker also no longer takes down the build. This would build on this PR, with a switch for comparing processes against domains.
2. Start long modules first. The scheduler currently starts whichever module is ready. Using each module's compile time from the previous build, it could start the longest ones, and those that many others wait for, as early as possible, so the build doesn't end with idle workers waiting for one late, slow module.
3. Allocate less. Every word allocated brings the next shared collection closer, and Gc.Memprof can show where typing allocates.
4. Less repeated work per module: a per-worker .cmi cache validated by digest, keeping ASTs in memory between parsing and compiling, and writing .cmt files off the critical path.
5. Faster incremental builds: keep loaded compiler state across watch-mode rebuilds.

ThreadSanitizer

An OCaml 5.5.0 ThreadSanitizer build of rescript reported no data races in compiler or rewatch code on clean builds of rewatch/testrepo (4 domains), tests/tests (2, 8 and 12 domains), the gentype example and the React PPX tests, or in the rewatch unit tests. Two reports appeared in some tests/tests runs, both inside the runtime's parallel minor GC (oldify_one against pool_allocate). With the shared Js_analyzer accumulator restored, the same tests/tests build reports 91 races, all in Js_analyzer, so the tool does catch this class of bug. This run predates publishing on the worker domains.

Tests

• The focused suite uses a large module to keep an in-process compile running. With it, it tests:
  • that a second build waits for the build lock;
  • that repeated signals still stop cleanly;
  • that TERM, HUP and QUIT during compilation stop with the signal's status;
  • that removing watch.lock stops a watcher's compile;
  • that an atomic save during a rebuild is built.
• It also tests:
  • that a damaged published AST is re-parsed;
  • that builds need no temporary directory;
  • that a failing PPX's stderr doesn't shift its error;
  • PPX temp files under a relative TMPDIR;
  • that a stop is noticed between namespace maps;
  • that a failed parse stays pending.
• Unit tests check that an exception escaping the compiler fails only its own module and that PPX cancellation returns promptly.
• rewatch-ocaml/bench compares clean-build artifacts across domain counts; it does not run in CI.

🤖 Generated with Claude Code